Skip to content

Derive the commits the signature reading is taken at - #228

Merged
iderex merged 1 commit into
mainfrom
parity/derive-the-commits-the-signature-reading-is-taken-at
Aug 30, 2026
Merged

Derive the commits the signature reading is taken at#228
iderex merged 1 commit into
mainfrom
parity/derive-the-commits-the-signature-reading-is-taken-at

Conversation

@iderex

@iderex iderex commented Aug 30, 2026

Copy link
Copy Markdown
Contributor

Refs #55

The signature subsection this issue's walk added to docs/quality-parity.md
introduced its verification paste as read at the three most recent non-merge
commits, and named 45bfe62, 2edacce and 43b4fae. Eleven non-merge commits
have landed since, so those are the twelfth, thirteenth and fourteenth:

git log origin/main --no-merges --format=%h | grep -n '^45bfe62\|^2edacce\|^43b4fae'
12:45bfe62
13:2edacce
14:43b4fae

Why this is the harder half of the class to see

The output under that paste was still right. Each of the three answers
true valid today:

for c in 45bfe62 2edacce 43b4fae; do
  gh api repos/Flowfin/lab/commits/$c --jq '.commit.verification | "\(.verified) \(.reason)"'
done
true valid
true valid
true valid

So a reader checking the evidence checks the output, finds it correct, and never
reaches the sentence above it, which was the part that had stopped reproducing.
The four earlier repairs to this section were all claims whose own paste had
gone wrong; this one is a claim whose paste was fine.

What the change does

The command now derives its own subjects instead of carrying three names, and
the paste is the reading it produced today:

for c in $(git log origin/main --no-merges -3 --format='%H'); do
  gh api repos/Flowfin/lab/commits/$c --jq '.commit.verification | "\(.verified) \(.reason)"'
done
true valid
true valid
true valid

The trio then moves with the branch, so this paragraph cannot go wrong in that
direction again, and what a re-run refuses instead is the thing the paragraph is
about: a commit reaching the default branch without a signature the platform
verifies. The paragraph below it records what stood there, why it was wrong and
how it was found, rather than the correction being made silently.

How I found it, and what else I read in the same pass

By running every command that section pastes before quoting a row back. Nothing
else in it moved. Read on 2026-08-30:

gh api repos/Flowfin/lab/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
pull_request
required_signatures
gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
required_status_checks
pull_request
required_signatures
gh api repos/Flowfin/lab/rules/branches/main \
  --jq '.[] | select(.type=="pull_request") | .parameters'
{"allowed_merge_methods":["merge","squash","rebase"],"dismiss_stale_reviews_on_push":false,"dismissal_restriction":{"allowed_actors":[],"enabled":false},"require_code_owner_review":false,"require_extra_approval_for_unattributed_changes":true,"require_last_push_approval":false,"required_approving_review_count":0,"required_review_thread_resolution":false,"required_reviewers":[]}
gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main \
  --jq '.[] | select(.type=="pull_request") | .parameters'
{"allowed_merge_methods":["merge"],"dismiss_stale_reviews_on_push":false,"dismissal_restriction":{"allowed_actors":[],"enabled":false},"require_code_owner_review":false,"require_extra_approval_for_unattributed_changes":true,"require_last_push_approval":false,"required_approving_review_count":0,"required_review_thread_resolution":false,"required_reviewers":[]}
gh api "repos/Flowfin/lab/rulesets/$(gh api repos/Flowfin/lab/rulesets \
  --jq '.[] | select(.name=="gate") | .id')" \
  --jq '{enforcement, bypass: .bypass_actors}'
{"bypass":[],"enforcement":"active"}
gh issue view 46 --repo Flowfin/lab --json state,closedAt --jq '"\(.state) \(.closedAt)"'
CLOSED 2026-08-27T08:46:01Z

The companion tracking item for this row, in a rule I keep elsewhere, is closed
too; I read it in the same pass.

The require_code_owner_review row rests on there being no CODEOWNERS file,
which also still holds:

git ls-tree -r --name-only origin/main | grep -i codeowners
exit=1

What this does not finish

It does not finish #55. That issue's remaining leg is allowed_merge_methods
on this board's ruleset, printed above as all three methods, and no change in
this tree reaches a ruleset parameter.

The means

Markdown prose edited inside the document this issue already built, because the
subject is a sentence in that document and the walk it belongs to asks a reader
to find the whole answer in one place. No language, runtime or dependency is
added, and the formatting is held by the prose check that already reads every
tracked .md file.

Where this sits against the other work in this file

The change is three hunks between lines 820 and 850, inside
## The rest of the ruleset, which is this issue's section. The sections above
it, ## Which contexts arrive, and on which pull requests and ## The gap this rests on, are #26's and #62's subjects and are untouched.

Checks run before pushing

go build ./cmd/... ./internal/...
go vet ./cmd/... ./internal/...
gofmt -l cmd internal
go test -count=1 ./cmd/... ./internal/...
ok  github.com/Flowfin/lab/internal/prose  1.484s
ok  github.com/Flowfin/lab/internal/invariants  1.839s

gofmt -l printed nothing and all thirteen packages passed.

What has not been read

This board has no second reader tonight, so nothing here has been read by
anybody but me, and the evidence above stands in place of that reading. The
verification paste is a reading of the API at one moment, which is the bound the
section's own closing subsection states for every row in it.

The signature subsection of docs/quality-parity.md said its verification paste
was read at the three most recent non-merge commits and named 45bfe62, 2edacce
and 43b4fae. Eleven non-merge commits have landed since, so those are the
twelfth, thirteenth and fourteenth, and the sentence above the paste had stopped
being true while the paste under it stayed correct.

That is the harder half of this class to see. A reader checking the evidence
checks the output, and all three still answer true valid; what had gone wrong
was the claim naming them. The command now derives its own subjects from
git log, so the trio moves with the branch and cannot go wrong in that direction
again, and what a re-run refuses instead is the thing the paragraph is about,
which is a commit reaching the default branch without a signature the platform
verifies.

I found it by running every command this section pastes before quoting a row
back, which is how the four earlier repairs to it were found as well. Nothing
else in the section moved: the rule types on both boards, the nine pull-request
parameter rows on both boards, the enforcement and bypass paste, the two issue
states and the timeline all return what the document gives them.

Refs #55. It does not finish that issue, whose remaining leg is a ruleset
parameter no change in this tree reaches.

Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
@iderex iderex self-assigned this Aug 30, 2026
@iderex
iderex merged commit 226c223 into main Aug 30, 2026
25 checks passed
@iderex
iderex deleted the parity/derive-the-commits-the-signature-reading-is-taken-at branch August 30, 2026 21:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant